Attorney's Docket No.: 13914-023001 / 2003P00069 US 



APPLICATION 
FOR 

UNITED STATES LETTERS PATENT 



TITLE: INTERFACE FOR GENERATING BUSINESS PARTNERS 

APPLICANT: PETER SCHWARZE, KARIN BRECHT-TILLINGER and 
TORSTEN REICHARDT 



CERTIFICATE OF MAILING BY EXPRESS MAIL 
Express Mail Label Nn F.V 348 1 89 065 US 

September 30. 2003 

Date of Deposit 



Attorney Docket No.: 13914/023001/2003P00069US 

INTERFACE FOR GENERATING 
BUSINESS PARTNERS 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] This application claims priority to U.S. 
Provisional Application Serial No. 60/427,509, filed on 
November 18, 2002, and entitled, "Web Service Integration". 



BACKGROUND 

[0002] The following description relates to electronic 
procurement systems. 

[0003] Companies may employ certain individuals to 
purchase products and/or services for the company. These 
professional purchasers may need to identify a pool of 
potential business partners to supply a product or service 
and then select from that pool. 

[0004] Professional purchasers may utilize electronic 
procurement systems to facilitate purchasing business 
processes. These systems may enable the company to reduce 
costs associated with purchasing by increasing supply chain 
visibility and automating business processes. Electronic 
procurement systems may also help the purchasers, and the 
company, build collaborative relationships with suppliers. 
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SUMMARY 

[0005] A system may enable users, such as professional 
purchasers for an enterprise, to create new business 
partners for the enterprise using information in business 
partner directories hosted by external service providers. 
The system may include an electronic procurement system 
that can perform the following operations: establish 
communication with a server including an external 
directory; send a request identifying a user-selected 
potential business partner in the external directory, 
receive a response from the external directory; the 
response including information relating to the selected 
potential business partner; parse the information in the 
response; and create a new business partner entry in the 
internal directory with the information parsed from the 
response . 

[0006] The electronic procurement system and external 
service providers may use a partner interface protocol to 
exchange partner information. The request and response may 
include information in a format compliant with the 
protocol . 

[0007] The new business partner may be created during a 
business process using the partner information. The new 
business partner may be approved in another process. The 



2 



Attorney Docket No.: 13914/023001/2003P00069US 

system may determine whether the user has approval to 
create a new business partner. If not, an authorized 
approver may be identified, and a workflow item created for 
the authorized approver. If the new business partner is 
ultimately not approved, the new business partner may be 
deleted from the internal directory and any document 
created using the new business partner information may be 
placed on hold. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0008] Figure 1 is a block diagram of a system 
supporting a partner interface. 

[0009] Figures 2A-2C show a flowchart describing a 
business partner creation operation. 

[0010] Figure 3 is a screen shot of a display in a 
sourcing application. 

[0011] Figure 4 shows an exemplary OPI outbound 
interface structure. 

[0012] Figure 5 shows a flowchart describing a business 
partner approval process . 

DETAILED DESCRIPTION 
[0013] Figure 1 shows a system 100 that includes an 
electronic procurement system 105 in an enterprise system 
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106 and one or more external service providers 107. The 
system may enable users of the electronic procurement 
system 105 to create business partners from an external 
business partner directory 108 hosted by an external 
service provider 107. The user may access the business 
partner directory 108 at the external service provider and 
create a business partner entry (or object) in the 
electronic procurement system during execution of a 
business process in the procurement system, e.g., assigning 
a source of supply (e.g., a vendor) for a product. 
[0014] The enterprise system 106 may include one or more 
clients 110 connected to an application server 109 through 
a network 115, e.g., a LAN (Local Area Network), WAN (Wide 
Area Network) , or Web portal . Users may interact with the 
application server 109 through the client 110, which may 
be, for example, a personal computer (PC) or a terminal 
connected directly to the application server 109. 
[0015] The electronic procurement system 105 may reside 
on the application server 109. The electronic procurement 
system 105 may include a number of services that support 
interaction with business partners and/or maintenance of 
business partner information. The services may include a 
sourcing cockpit 12 0, a bidding engine 121, and a business 
partner maintenance service 122. The sourcing cockpit 120 
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may enable a user to search for and select a company 
approved vendor to source a particular product. The 
bidding engine 121 may enable the user to create bid 
invitations for an auction and host and participate in the 
auction. The business partner maintenance service 122 may 
enable the user to create new business partners and update 
existing business partner information. The business 
partner maintenance service 122 may include an internal 
business partner directory 123, which may include a list of 
company- approved vendors (flagged as "released") and/or 
vendors pending approval (flagged as "not_released") and 
backend contracts for certain products or product 
categories . 

[0016] In an embodiment, the user can create a business 
partner, e.g., as an object in the internal directory 123, 
during execution of a business process in any of the 
services 120-122 provided by the procurement system. For 
example, Figures 2A-2C is a flowchart describing an 
exemplary business partner creation operation performed 
during a sourcing process in the source cockpit service 
120 . 

[0017] Figure 3 shows an exemplary screen display 300 
for the sourcing process. The screen display 300 includes 
a work list 305 including descriptions of products to 



5 



Attorney Docket No.: 13914/023001/2003P00069US 

source (work items), a work area 310, a pull down menu 315, 
and an external services link button 320 to call external 
web services. In an embodiment, the user can select an 
item from the work list 305 and pull it into the work area 
310 (block 205) (Figure 2A) . The user may then select a 
business partner to source the product in the work item 
(block 210) . 

[0018] The work area 310 includes a field 325 for 
searching for a supplier from existing business partners in 
the electronic procurement system. The user may select 
from these existing business partners, e.g., by pulling up 
the internal direction 123 in a separate window and 
entering an existing business partner from the directory in 
the field 325. The user may also have the opportunity to 
select a new business partner from the external business 
partner directory 108. The procurement system 105 may 
provide one or more external service providers in the pull 
down menu 315. The user may select an external service 
provider from the pull down menu 315 and then press the 
external services link button 320 (block 215) . 
[0019] The enterprise system 106 may communicate with 
the external service provider 107 using a partner interface 
protocol. The partner interface may be, for example, the 
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Open Partner Interface (OPI) developed by SAP AG of 
Waldorf, Germany. 

[0020] The OPI uses standard Internet protocols, e.g., 
HTTP (Hypertext Transfer Protocol) , to exchange information 
between the application server 10 9 and the external service 
providers. Using the OPI, the electronic procurement 
system 105 may send a request in an OPI -compliant format to 
an external service provider, and the external service 
provider may return a response page, which includes results 
compiled in response to the request, in an OPI -compliant 
format . 

[0021] The OPI includes an outbound interface and an 
inbound interface. The outbound interface consists of 
information that is sent to the external service provider 
107 by an OPI module 112 at the electronic procurement 
system 105. This information originates in the electronic 
procurement system 105, where it is created and maintained. 
The information may be stored in fields in an internal 
table. Every field may contain a name-value pair and have 
a type. The information stored in the table for each 
external service provider may include the following 
information: the external service provider URL (Uniform 
Resource Locator) , which should refer to the location of 
the external partner directory; fields specific to the 
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external service provider, such as username and password ,- 
and a return URL used by the external service provider 107 
to return to the electronic procurement system 109. 
[0022] Using the information in the internal table, the 
electronic procurement system 105 constructs a URL call to 
the external service provider and may redirect a web 
browser 130 at the client to this URL. In an embodiment, 
the external service provider may be accessed using the 
HTTP methods GET or POST, which includes the outbound 
interface field data. The external service provider 107 
then parses and decodes this data and may perform a search 
of the external business partner directory 108 based on the 
data . 

[0023] The OPI inbound interface consists of information 
that is sent to the electronic procurement system 105 by 
the external service provider 107. The inbound interface 
may be sent back to the electronic procurement system in an 
OPI-compliant form, e.g., an HTML page or an XML file. For 
each item selected in the external business partner 
directory 108 and sent to the electronic procurement 
system, all required fields must be sent, along with the 
optional fields. The fields may include the following 
information: name of the organization; language; address; 
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telephone number; fax number; and e-mail address. Figure 4 
shows exemplary fields for an OPI inbound interface. 
[0024] As described above, when the user selects an 
external business partner directory (block 215) , the 
procurement system constructs the URL call to the external 
service provider and redirects the user's browser 130 to 
the external business partner directory. The directory may 
be opened in a separate window on the client display screen 
(block 220) . The user may then select a new business 
partner (e.g., vendor) from the directory (block 225). The 
external service provider constructs a response form (e.g., 
HTML page) according to the partner interface protocol, 
which includes the required partner information in the 
appropriate fields, and sends the response page to the 
procurement system. The procurement system imports the 
data from the response page (block 230) . The procurement 
system may then parse and map the imported business partner 
data to an internal table (block 23 5) (Figure 2B) . 
[0025] In an embodiment, when a business partner (e.g., 
a vendor) is selected from an external business partner 
directory, the procurement system may determine if the 
business partner already exists in the internal business 
partner directory 123 to prevent double entries (block 
240) . The check may be a string comparison or fuzzy search 
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of the vendor's name with entries in the internal directory 
123. As described above, business partners in the internal 
business partner directory may be flagged as "released" 
(approved) or "not_released" . If the vendor does exist in 
the internal directory, the system may determine if the 
vendor is approved (block 250) (Figure 2A) . If the vendor is 
approved, the user may continue with the purchasing process 
using the released vendor guid ("globally unique 
identifier") in the internal directory (block 255) . If the 
vendor is not approved, the user may continue the 
purchasing process with the not_released vendor guid (block 
260). Any purchasing documents (e.g., a purchase order) 
generated in the purchasing process using the not_released 
vendor guid may be placed "on hold" in the system (block 
265) . The purchasing document will remain on hold until 
approved by an authorized approver, e.g., a manager of the 
purchasing organization. 

[0026] If the vendor does not exist (block 240, Figure 
2B) , the OPI information in the internal table may be used 
to create a new business partner entry (or object) in the 
internal business partner directory and assign a 
"not_released" vendor guid to the new business partner 
(block 270) . The not_released status may indicate that the 
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associated business partner entry is incomplete and/or 
unapproved . 

[0027] The user may or may not have authority to create 
a business partner. This authority may be based on the 
user's role. A professional purchaser would probably have 
authority to create a business partner, whereas other users 
of the system may not . The procurement system determines 
whether approval is required (block 275) (Figure 2C) , e.g., 
by checking the role associated with the user. If approval 
is not required, the new business partner may be flagged as 
released in the internal business partner directory (block 
280) , and the user may then continue with the purchasing 
process with the released vendor guid (block 285) . Other 
purchasers in the relevant purchasing group may also be 
notified of the new approved vendor, e.g., by email 
notification (block 287) . 

[0028] If approval is required, the new business partner 
may be flagged as a not_released (block 290) . The user may 
then continue with the purchasing process with the 
not_released vendor guid (block 2 92) . Any purchasing 
documents generated in the purchasing process using the 
not_released vendor guid may be placed on hold in the 
system (block 2 94) . 
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[0029] The creation of the new, not_released business 
partner, may trigger a business partner approval process 
500. Figure 5 is a flowchart describing a process 500 for 
approving a new business partner. The procurement system 
may determine an approver in response to the creation of 
the new, not_released business partner (block 505) . The 
approver may be, e.g., the manager of the purchase 
organization to which the user belongs. The system may 
then create a workflow item with the vendor guid in the 
approver's inbox (block 510). When the approver opens the 
workflow item, the business partner maintenance service may 
be launched in a new transaction window. The approver may 
then approve or reject the new business partner (block 
515) . 

[0030] If the vendor is rejected, the system may delete 
the business partner from the internal directory, and any 
other business partner sets in the procurement system, that 
contain the rejected business partner (520) . The 
procurement system may then send notification emails to the 
user and any other purchasers that have created purchase 
orders using the rejected business partner and to the 
business partner indicating the rejected status (block 
525) . The concerned procurement documents may remain in 
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work lists with the "on hold" for further consideration or 
appeal . 

[0031] If the business partner is approved, the system 
may send notification e-mails to the user and other 
purchasers that have created purchasing orders with the 
approved business partner (block 530) and the new business 
partner may then be assigned to relevant purchasing orders 
(535) . 

[0032] In an embodiment, the external business partner 
directory 105 may include more detailed information about a 
business partner in the internal directory 123. The user 
may be able to access this additional information during a 
business process through the OPI interface. 
[0033] A number of embodiments have been described. 
Nevertheless, it will be understood that various 
modifications may be made without departing from the spirit 
and scope of the invention. For example, blocks in the 
flowcharts may be skipped or performed out of order and 
still produce desirable results. Accordingly, other 
embodiments are within the scope of the following claims. 
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